IBIS Macromodel Task Group

Meeting date: 05 January 2016

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI):                  Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- Arpad welcomed everyone back for 2016 and reminded them that there will be no
  ATM meeting on January 19th because DesignCon and the associated IBIS summit
  occur that week.

- Arpad noted that he will attend DesignCon and deliver an ATM group status
  presentation.

--------------------------
Call for patent disclosure:

- None.

-------------
Review of ARs:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
Discussion of language corrections regarding "ground":
- Arpad: [Sharing Walter's recent document that listed all lines/paragraphs in
          which "GND" appeared]
- Walter: In almost all examples in the spec, it is clear from context whether
          GND is a Model name or a signal_name.
  - In general, I think the new paragraph works with 3 considerations:
    - 1. We could change all signal_name uses from GND to VSS to eliminate
         confusion.  I know Arpad and Bob R. object to that.
    - 2. We could just leave them and let the reader figure it out from context.
    - 3. We could insert additional comments in any place where it's not a Model
         name or signal_name.
  - In the figures and graphics, we have to look at each one where GND is used
    or the ground symbol is used.
    - In many cases we can replace the use of the ground symbol with “GND,” but
      not all.
  - I've highlighted in red the "GND" references in the text that I thought were
    not obvious.  I have not yet done a similar exercise for "GROUND."
- Discussion: Radek reiterated that he felt an important part of this exercise
  was clarifying the reference terminal for the signal pad.  Walter agreed and
  said that if a receiver has threshold voltages (e.g., Vinl, Vinh) they have to
  be referenced to the same point the I/O (signal) pad is referenced to, and
  that it must be a local node on the buffer.  It would have to be relative to
  some local ground.  For every buffer, we need to know which one of the five
  voltages in [Pin Mapping] is the local reference.  Bob R. objected to that and
  said that while Walter's description was physically reasonable, it was not the
  case for IBIS.  He said that the various reference voltages in IBIS were all
  single valued entries with an implicit reference to absolute 0 (node 0).
  Radek said that implicit connection to node 0 was assumed in the past, but
  that our goal was to clarify the text and move beyond that assumption.  Walter
  stated that Bob's interpretation was based on the discussions about test
  fixturing and measurements.  The test fixture discussions assumed the
  pd or gc reference for a buffer is tied to the same reference as the fixture,
  which is absolute zero.  But in terms of simulation for things like Vinl, they
  are typically going to be with respect to some local reference, most likely
  pd_ref or gc_ref terminals.  Bob said we would have to be very careful in
  describing the new rules to avoid breaking existing Models.  Bob and Mike L.
  pointed out a paragraph, on page 72 of the IBIS 6.1 spec, that described
  Composite Current extraction and used the term "absolute GND."  Walter pointed
  out that this was with respect to test fixtures.  Arpad and others objected
  to other elements of the paragraph including the term "absolute GND" itself,
  and the suggestion that it could serve as a reference for C_comp.  Arpad noted 
  that everyone had rejected the idea of connecting C_comp to node 0, and stated 
  that it should be tied to some local ground.  He suggested that there had been 
  reluctance to specify that it be tied to the pd_ref or gc_ref terminals in
  case those were not the local ground pins, but we had not provided any way to
  specify the additional local reference we needed if the other two were
  non-zero.  Radek agreed and said he would support adding a new reference
  terminal and did not support forcing pd_ref or gc_ref to be used as the
  reference.  Bob worried that any of the discussed changes would involve
  substantial parser modifications, but Radek thought it might simply clarify
  things that had been implicit.
- Discussion:  Bob R. and Mike L. pointed out an example IBIS file that had been
  created for ibischk BUG 172.  The example contained [Pin] and [Pin Mapping]
  sections that defined two "POWER" Pin associated buses providing positive
  voltage rails, a "GND" Pin associated bus providing a 0V rail, and two
  additional "POWER" Pin associated buses providing negative voltage rails.  One
  I/O Pin used the VSS "GND" bus as its pd_ref and one of the positive voltage
  "POWER" buses as its pu_ref.  Another I/O Pin used one of the negative voltage
  "POWER" buses as its pd_ref and the VSS "GND" bus as its pu_ref.  This example
  illustrated problems we would have defining the "reference" terminal from
  amongst the five existing terminals defined by [Pin Mapping].  Mike L. pointed
  out that we might have simply called the buses "rails" instead of "POWER" and
  "GND".  Bob said gc_ref was a misnomer and something like vss_ref might have
  been better.  Arpad understood Bob's point, but said he had always objected to
  use of VSS because it was specific to transistor technology.  Walter said the 
  example pointed out the need to come up with constant rules for what was the
  reference terminal, perhaps pd_ref, or gc_ref, or whatever reference had Model
  name "GND."  But Bob pointed out another Pin from the same example that had
  no reference using "GND" ("POWER" buses were used for all reference
  terminals).  In this example the "POWER" buses used as references were at
  -2.5V and +2.5V.  Everyone agreed that we have to clean up the overloaded use
  of the reference voltage terms ([Voltage Range], [POWER Clamp Reference],
  etc.), which are sometimes interpreted as ideal voltage values relative to
  ideal 0 (during extraction), and sometimes interpreted as terminals between
  which voltages are calculated for table lookup during simulation.

- Arpad: I think we are starting to agree on the concepts that need work.
  - How many BIRDs might we be talking about?  It seems like these 4 Voltage
    keywords themselves need work, as well as the ground cleanup.
  - Thank you all for joining.
-------------
Next meeting: 12 January 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
